8.3 Troubleshooting VLANs  
  8.3.5 VLAN troubleshooting scenarios  
Proficiency at troubleshooting switched networks will be achieved after the techniques are learned and are adapted to the company needs. Experience is the best way of improving troubleshooting skills.

Three practical VLAN troubleshooting scenarios referring to the most common problems will be described. Each of these scenarios contains an analysis of the problem to then solving the problem. Using appropriate specific commands and gathering meaningful information from the outputs, the progression of the troubleshooting process can be completed.

Scenario 1: A trunk link cannot be established between a switch and a router.

When having difficulty with a trunk connection between a switch and a router, be sure to consider the following possible causes:

  1. Make sure that the port is connected and not receiving any physical-layer, alignment or frame-check-sequence (FCS) errors. This can be done with the show interface command on the switch.
  2. Verify that the duplex and speed are set properly between the switch and the router. This can be done with the show int status command on the switch or the show interface command on the router.
  3. Configure the physical router interface with one subinterface for each VLAN that will route traffic. Verify this with the show interface IOS command. Also, make sure that each subinterface on the router has the proper encapsulation type, VLAN number, IP address, and subnet mask configured. This can be done with the show interface or show running-config IOS commands.
  4. Confirm that the router is running an IOS release that supports trunking. This can be verified with the show version command.

Scenario 2: VTP is not correctly propagating VLAN configuration changes.

When VTP is not correctly affecting configuration updates on other switches in the VTP domain, check the following possible causes:

  1. Make sure the switches are connected through trunk links. VTP updates are exchanged only over trunk links. This can be verified with the show int status command.
  2. Make sure the VTP domain name is the same on all switches that need to communicate with each other. VTP updates are exchanged only between switches in the same VTP domain. This scenario is one of the most common VTP problems. It can be verified with the show vtp status command on the participating switches.
  3. Check the VTP mode of the switch. If the switch is in VTP transparent mode, it will not update its VLAN configuration dynamically. Only switches in VTP server or VTP client mode update their VLAN configuration based on VTP updates from other switches. Again, use the show vtp status command to verify this.
  4. If using VTP passwords, the same password must be configured on all switches in the VTP domain. To clear an existing VTP password, use the no vtp password password command on the VLAN mode.

Scenario 3: Dropped packets and loops.

Spanning-tree bridges use topology change notification Bridge Protocol Data Unit packets (BPDUs) to notify other bridges of a change in the spanning-tree topology of the network. The bridge with the lowest identifier in the network becomes the root. Bridges send these BPDUs any time a port makes a transition to or from a forwarding state, as long as there are other ports in the same bridge group. These BPDUs migrate toward the root bridge.

There can be only one root bridge per bridged network. An election process determines the root bridge. The root determines values for configuration messages, in the BPDUs, and then sets the timers for the other bridges. Other designated bridges determine the shortest path to the root bridge and are responsible for advertising BPDUs to other bridges through designated ports. A bridge should have ports in the blocking state if there is a physical loop.

Problems can arise for internetworks in which both IEEE and DEC spanning-tree algorithms are used by bridging nodes. These problems are caused by differences in the way the bridging nodes handle spanning tree BPDU packets, or hello packets, and in the way they handle data.

In this scenario, Switch A, Switch B, and Switch C are running the IEEE spanning-tree algorithm. Switch D is inadvertently configured to use the DEC spanning-tree algorithm.

Switch A claims to be the IEEE root and Switch D claims to be the DEC root. Switch B and Switch C propagate root information on all interfaces for IEEE spanning tree. However, Switch D drops IEEE spanning-tree information. Similarly, the other routers ignore Router D's claim to be root.

The result is that in none of the bridges believing there is a loop and when a broadcast packet is sent on the network, a broadcast storm results over the entire internetwork. This broadcast storm will include Switches X and Y, and beyond.

To resolve this problem, reconfigure Switch D for IEEE. Although a configuration change is necessary, it might not be sufficient to reestablish connectivity. There will be a reconvergence delay as devices exchange BPDUs and recompute a spanning tree for the network.

 

Web Links

VLAN Tech Notes

http://www.cisco.com/en/US/tech/ tk389/tk689/ tech_tech_notes_ list.html